As computing needs for organizations have increased, and as organizations plan for growth, one common way to plan for, and obtain economical computing is to purchase computing systems that are scalable. A system or architecture is scalable when it can be upgraded or increased in size or reconfigured to accommodate changing conditions. For example, a company that plans to set up a client/server network may want to have a system that not only works with the number of people who will immediately use the system, can be easily and economically expanded to accommodate the number of employees who may be using the system in one year, five years, or ten years. In another example, a company that runs a server farm and hosts web pages or applications via the Internet may continue to grow, and this company would desire a scalable system where they can economically add servers as needed to accommodate growth and can re-partition as needed.
Accordingly a scalable system can typically merge or integrate a number of scalable servers or chassis having one or more processors to create a “larger” unitary system having processing nodes. Thus, a collection of scalable servers can function like a single larger server when properly merged. Although multiple servers are merged they can also be partitioned using hardware partitioning. A system with a single partition can run a single instance of an operating system (OS) and all the nodes of the system are thus conceptually combined. Thus, in effect the user will experience a single, more powerful computing system functioning as one “scaled up” node, instead of a number of less powerful nodes running independently.
A traditional approach to combining multiple nodes of a system into a single-partition merged system running a single instance of an OS is to have a trained technician manually integrate and configure each node as a system is built or as computing resources (nodes) are added. Traditionally, a trained technician or administrator must configure each node with the proper partition configuration information, specifying one of the nodes as the primary, or boot node, and the other nodes as secondary nodes to the primary node. This approach is cumbersome, and requires trained technicians to build and configure such a system. When there are more than a few nodes to manually configure, configuring can get complex and such configuring is prone to connection and configuration errors and omissions.
Another approach is to have dedicated hardware that is responsible for configuring the nodes as a single-partition merged system running a single instance of an OS. In this approach an administrator can interact with the dedicated hardware, which may be, for example, a dedicated management console. The dedicated hardware can be responsible for ensuring that the nodes operate as a single-partition merged system. It can be appreciated that this approach requires costly dedicated hardware, and may require modification to preexisting systems that do not allow for the addition of such functionality.
Power up for a scalable system also can create difficulties. One approach to address this issue is to have a “luck-of-the-draw” or timing-based approach programmed into the nodes of the system. When a node boots up, it can determines whether a single-partition merged system is already running, and if so, join the system. If the node does not find a preexisting system to join, it starts one, and becomes the primary node for the new system. The node thus becomes the primary node due to timing issues and the luck of the draw. Such an approach, however, can be complex, and does not provide the administrator with control over which node becomes the primary node. Generally, systems in a scalable environment don't automatically know that they are cabled together and can work as one system. These scalable systems have to be told (i.e. configured by technician) such that they know that they are cabled to other nodes and must be configured regarding how they can communicate with other nodes. There are many current designs available that utilize this manual configuration approach. One design uses a network such as an Ethernet connection between nodes and utilizes a Remote Supervisor Adapter (RSA) to facilitate set up of the system.
The RSAs can communicate with each other on Ethernet (embedded service on each RSA) and can instruct the scalable components to work together with a set partitioning. This system, among other things, requires a user to input the Internet Protocol (IP) addresses of each RSA in the RSA interface before the scalable systems can work as a single entity. This process can be cumbersome for a user to discover and enter the RSA IP address for each component. This IP detection process can include booting each scalable component and after the component is connected to the network the user can request and find the IP address in the BIOS menu of the component. Another traditional arrangement uses a Service Location Protocol (SLP) discovery routine to detect all scalable components via the system's RSA Ethernet network connections. Then the arrangement can iterate through the list of SLP scalable systems and an application can send a message (ping) through each scalable system port and detect received messages on another scalable system port. Each scalable system relies on RSA Ethernet protocol to initiate and detect how other scalable systems interconnect. In the end, all scalable connections are determined for all SLP scalable systems.
This Ethernet based arrangement does not get comprehensive system information and such a detection depends on intercommunication of scalable components via RSA Ethernet. This solution uses SLP to discover the communication mechanism, which can find a large number of systems. Only the number of RSAs connected to that network limits the number of discovered systems. Often not all of these detected systems can be operate as a single identity. This can cause extra time filtering through the systems not capable of scalability.
Another approach is to connect the servers and configure virtual building blocks. These building blocks can be broken down to any level, but this is only supported in a Linux environment. Traditional systems require intensive user configuring the system utilizing a remote service administrator (RSA). Traditional systems utilize a relatively complex set-up. Such as set up can also require extensive hardware and software overhead. For example, such a system can require an Ethernet communication system to communicate set up commands to all of the subsystems. Further, it is expensive to require a trained technician be present at every installation or every system expansion.